home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
QRZ! Ham Radio 3
/
QRZ Ham Radio Callsign Database - Volume 3.iso
/
digests
/
tcp
/
930191.txt
< prev
next >
Wrap
Internet Message Format
|
1994-06-04
|
14KB
Date: Tue, 27 Jul 93 04:30:05 PDT
From: Advanced Amateur Radio Networking Group <tcp-group@ucsd.edu>
Errors-To: TCP-Group-Errors@UCSD.Edu
Reply-To: TCP-Group@UCSD.Edu
Precedence: Bulk
Subject: TCP-Group Digest V93 #191
To: tcp-group-digest
TCP-Group Digest Tue, 27 Jul 93 Volume 93 : Issue 191
Today's Topics:
convers-ping-pong release 1.18
conversd for wampes
OS/2 NOS version status and misc
sbrk() declaration ????
Undelivered mail (2 msgs)
Z80 SIO and SCC (2 msgs)
Send Replies or notes for publication to: <TCP-Group@UCSD.Edu>.
Subscription requests to <TCP-Group-REQUEST@UCSD.Edu>.
Problems you can't solve otherwise to brian@ucsd.edu.
Archives of past issues of the TCP-Group Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives".
We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party. Your mileage may vary. So there.
----------------------------------------------------------------------
Date: Mon, 26 Jul 93 11:11:19 CDT
From: andyw@aspen.cray.com (Andy Warner)
Subject: convers-ping-pong release 1.18
To: dc6iq@insu1.etec.uni-karlsruhe.de
Fred wrote:
> > [...]
> > from the convers.conf file
> > hostname
> > host host:3600
> >
> > which will make the Linux kernel (net-2) to make a tcpip connect to the
> > host named in the convers.conf :3600 being the port number..
> > Over slow links via my router (wnos) the conversd program appears to hand up
> > untill the perm link is established once established any other logins to the
> > conversd works fine...
>
> This is normal - You should use this to connect via ethernet, not over
> slow links.
If the code looks at all like the "vanilla" conversd.c, you can just put
a p->retrytime = 0; after the call to update_permlinks() in
read_configuration(). I think this has the effect of establishing the
permlinks asynchronously. I did this when I couldn't figure out how
else to connect slow permlinks....
> [...]
I have some users who telnet directly to port 3600 on my
(SunOS based) converse server. It appears that conversd does
not use CRLF to terminate lines - should this be viewed as
a bug in conversd, or should they manually have to tweak their
telnet options ? (tricky call without any definative converse
specification :-))
--
andyw. N0REN/G1XRL
andyw@aspen.cray.com Andy Warner, Cray Research, Inc. (612) 683-5835
------------------------------
Date: Mon, 26 Jul 93 16:49:35 CET
From: BARRY TITMARSH <BTITMARS%ESOC.BITNET@vm.gmd.de>
Subject: conversd for wampes
To: TCP-GROUP <TCP-GROUP@ucsd.edu>,
Ok thanks for the infomation on the new version, on the ftp-site.
noted your comments on the host host:socket_number in the convers.conf
the new version works fine even with sym links for the other copies of
the daemon `conversd`
Again thanks for takeing the time out to produce it.
Barry G8SAU/DC0HK @ various IP's
------------------------------
Date: Mon, 26 Jul 93 09:26:20 cst
From: kf5mg@vnet.IBM.COM
Subject: OS/2 NOS version status and misc
To: TCP-Group@UCSD.Edu
Tried sending a message to Walt C. asking about NOS and PMAIL for OS/2.
My message got returned as undeliverable. You still out there Walt?
Wondering if you've made any progress on your new versions of tcp/ip for
OS/2. Also wanted to know if the source for PMAIL was available and if
you've played with the Borland, OS/2 compiler.
73's de Jack - kf5mg
Internet - kf5mg@kf5mg.ampr.org - 44.28.0.14
AX25net - kf5mg@kf5mg.#dfw.tx.usa.na - home (817) 488-4386
Worknet - kf5mg@vnet.ibm.com - work (817) 962-4409
------------------------------
Date: Mon, 26 Jul 93 07:31:27 -0700
From: karn@qualcomm.com (Phil Karn)
Subject: sbrk() declaration ????
To: J.R.Jagger@sheffield-hallam.ac.uk
I rewrote the grabcore() routine. It now calls DOS's memalloc() routine
instead of sbrk(). You should start with a more recent version of the code
if you want to hack it down, there are a lot of bug fixes there, not just
code growth.
Phil
------------------------------
Date: Wed, 21 Jul 93 17:15:24 MET
From: MAILER@CSPGUK11.BITNET (Network Mailer)
Subject: Undelivered mail
To: MAILER%CSPGUK11.BITNET@Sdsc.Edu
----------------------------Original message----------------------------
----------------------------Original message----------------------------
Your mail was not delivered to some or all of its
intended recipients for the following reason(s):
No such local user: RSCS
--------------------RETURNED MAIL FILE--------------------
Received: by CSPGUK11 (Mailer R2.07) id 0957; Wed, 21 Jul 93 17:15:24 MET
Date: Wed, 21 Jul 93 17:02:34 MET
From: Network Mailer <MAILER@CSPGUK11>
Subject: Undelivered mail
To: RSCS@CSPGUK11
Your mail was not delivered to some or all of its
intended recipients for the following reason(s):
FROM: or SENDER: inconsistent with spool file origin.
--------------------RETURNED MAIL FILE--------------------
Received: by CSPGUK11 (Mailer R2.07) id 0222; Wed, 21 Jul 93 17:02:35 MET
Received: from ucsd.edu by Sdsc.Edu (sds.sdsc.edu STMG) via INTERNET;
Sun, 18 Jul 93 08:21:17 GMT
Received: by ucsd.edu; id AB03154
sendmail 5.67/UCSD-2.2-sun
Sat, 17 Jul 93 23:24:29 -0700
Errors-To: tcp-group-relay@ucsd.edu
Sender: tcp-group-relay%UCSD.EDU@Sdsc.BITnet
Precedence: List
Received: from plains.NoDak.edu by ucsd.edu; id AA03148
sendmail 5.67/UCSD-2.2-sun via SMTP
Sat, 17 Jul 93 23:24:27 -0700 for /usr/mail/listhandler tcp-group
Received: by plains.NoDak.edu; Sun, 18 Jul 1993 01:24:25 -0500
From: ortmann%plains.NoDak.edu%UCSD.EDU@Sdsc.BITnet (Daniel Ortmann)
Message-Id: <199307180624.AA00833@plains.NoDak.edu>
Subject: NOS on MS-Windows?
To: tcp-group%UCSD.EDU@Sdsc.BITnet (tcp group)
Date: Sun, 18 Jul 93 1:24:24 CDT
X-Mailer: ELM [version 2.3 PL11]
1) Has anyone compiled any of the NOS family on MS-Windows?
2) Has anyone done it using MS Visual C++??
3) If it has not been done, then what are your thoughts on the difficulty?
--
Daniel "un?X" Ortmann (talmid) NDSU Electrical Engineering
ortmann@plains.nodak.edu shalom Fargo, North Dakota
------------------------------
Date: Wed, 21 Jul 93 17:15:34 MET
From: MAILER@CSPGUK11.BITNET (Network Mailer)
Subject: Undelivered mail
To: MAILER%CSPGUK11.BITNET@Sdsc.Edu
----------------------------Original message----------------------------
Your mail was not delivered to some or all of its
intended recipients for the following reason(s):
No such local user: RSCS
--------------------RETURNED MAIL FILE--------------------
Received: by CSPGUK11 (Mailer R2.07) id 0986; Wed, 21 Jul 93 17:15:34 MET
Date: Wed, 21 Jul 93 17:03:00 MET
From: Network Mailer <MAILER@CSPGUK11>
Subject: Undelivered mail
To: RSCS@CSPGUK11
Your mail was not delivered to some or all of its
intended recipients for the following reason(s):
FROM: or SENDER: inconsistent with spool file origin.
--------------------RETURNED MAIL FILE--------------------
Received: by CSPGUK11 (Mailer R2.07) id 0269; Wed, 21 Jul 93 17:03:00 MET
Received: from ucsd.edu by Sdsc.Edu (sds.sdsc.edu STMG) via INTERNET;
Sat, 17 Jul 93 07:40:24 GMT
Received: by ucsd.edu; id AA13632
sendmail 5.67/UCSD-2.2-sun
Fri, 16 Jul 93 22:44:45 -0700
Errors-To: tcp-group-relay@ucsd.edu
Sender: tcp-group-relay%UCSD.EDU@Sdsc.BITnet
Precedence: List
Received: from SABEA-OC.AF.MIL by ucsd.edu; id AA13618
sendmail 5.67/UCSD-2.2-sun via SMTP
Fri, 16 Jul 93 22:44:33 -0700 for /usr/mail/listhandler tcp-group
Received: by sabea-oc.af.mil (5.59/25-eef)
id AA26398; Sat, 17 Jul 93 00:41:09 CDT
From: ssampson%sabea-oc.af.mil%UCSD.EDU@Sdsc.BITnet (Mr. Sampson)
Message-Id: <9307170541.AA26398@sabea-oc.af.mil>
Subject: 9600 Experiances
To: TCP-Group%UCSD.EDU@Sdsc.BITnet
Date: Sat, 17 Jul 1993 00:41:05 -0500 (CDT)
X-Mailer: ELM [version 2.4 PL13]
Content-Type: text
Content-Length: 1149
Swinging to the hardware side for a moment...
I've recently been experimenting with 2 meter FM 9600 (have a
lot of experiance with a Tekk on 440) and am amazed at how
poorly it performs. I modified an ICOM 228A both to keep the
receiver on all the time (it shuts it off during transmit as
designed) and the normal VCO and Discriminator taps. After
discussing it, I'm pretty much convinced that the final IF
filter is the culprit. I'm using a PacComm TNC which has a
5 kHz cut-off on its input filter.
My theory is that 4800 Hz is the highest modulating frequency,
so the modulation index at 3 kHz deviation would be .625. Using
a Bessel chart shows +/- 3 sidebands for (6 x 4800) 28.8 kHz
Bandwidth. I assume the FIR filter on transmit greatly
attenuates the third sideband so we probably only need (4 x
4800) or 19.2 kHz.
The trouble is my ICOM (and most other rigs) has a 455 kHz filter
marked with an 'E'. PacComm says an 'E' is 15 kHz and a 'D' is
20 kHz. I'm not sure what the 10.7 MHz IF has in it. What's the
general consensus on this? Do those running 9600 sucessfully change
these out, or is my math all wrong?
---
Steve N5OWK
------------------------------
Date: Mon, 26 Jul 93 12:39:05 BST
From: A.D.S.Benham@bnr.co.uk
Subject: Z80 SIO and SCC
To: TCP-Group@UCSD.Edu
I've been trying to sort out a bug in the KISS ROM for the TNC-220, and during the course
of this I've come across something odd with the use of the Z80 SIO and SCC chips.
As the SCC chip (8530) is also used for NOS, I've got the same "problem" with the code
for the SCC driver.
Am I being stupid, or is there really a problem?
Both the SCC and SIO chips use a two-stage method to access their internal registers: a
write operation to the control register to specify the internal register to be accessed,
and then a read or write operation to the control register to actually access the register.
Now all the code I've been looking at has internal registers being accessed =both= by
foreground routines and by interrupt routines. This is where I have a problem.
Take the following examples:
=========================
Foreground Code
...
Write to Control Register, specifying register 4
Read Control Register
...
(This reads register 4)
=========================
Interrupt Code
...
Write to Control Register, specifying register 3
Write to Control Register
...
(This writes to register 3)
===========================
Now each routine works fine =in isolation=. But what happens if an interrupt occurs whilst
the foreground code is executing the "Write to Control Register, specifying register 4"
instruction?
As I see it, the processor will finish the instruction (so the internal register pointer
is set to point to register 4), and then call the interrupt routine.
The interrupt routine will do the "Write to control Register, specifying register 3"
instruction, except that this will be taken by the chip as a write operation to
register 4. The chip then resets the internal register pointer to point to register 0.
Now the interrupt routine sends the data it thinks it is writing to register 3, except
the chip is expecting a "set register pointer" instruction - so the register pointer
could be set to an unspecified value.
Then the interrupt routine returns, and the foreground routine continues and does the
control register read... except the internal register pointer is probably not pointing
to the right register any more.
So, in this example, both the foreground and interrupt routines have executed code which
is not that which was intended (in my experience, this is "a bad idea").
I'd have expected that if foreground and background tasks could both access the chip,
then the foreground code would mask interrupts during the two-operation access cycle
(in other words, as the access operation is not atomic, a locking mechanism is needed).
The Z80 SIO and SCC are at least 10 years old though, and the TNC KISS ROMs don't have
any special coding to get around this problem.
(I was expecting
Disable Interrupts
Write to Control Register, specifying register pointer
Read/Write Control Register
Enable Interrupts
in the foreground routine. The interrupt routines in the KISS ROMs can't themselves be
interrupted, so they need no additional work).
So am I being particularly thick and missed something fundamental? Or is there really
a potential problem lurking in lots of code?
Andrew Benham
--------------------------------------------------------------------
adsb@bnr.co.uk BNR Europe Ltd, London Road, Harlow, Essex CM17 9NA
adsb@bnr.ca +44 279 402372 Fax: +44 279 402029
Home: g8fsl@g8fsl.ampr.org [44.131.19.195] G8FSL@GB7HSN
--------------------------------------------------------------------
------------------------------
Date: Mon, 26 Jul 93 07:29:47 -0700
From: karn@qualcomm.com (Phil Karn)
Subject: Z80 SIO and SCC
To: A.D.S.Benham@bnr.co.uk
I wrap a "disable/restore" sequence around my references to the SCC's
registers. That makes the accesses atomic.
Phil
------------------------------
End of TCP-Group Digest V93 #191
******************************
******************************